Data management system of a real-time system

ABSTRACT

Data management systems of real-time systems are intended to provide user systems with rapid and consistent on-line management of various data generations. This is achieved by an access data structure which allows a generations management system (GMS) to carry out the management of various data generations on the basis of the same data objects already used on a previous occasion by a transaction management system (TMS) for carrying out transactions.

BACKGROUND OF THE INVENTION

Data management systems of real-time systems are intended to offer theiruser systems rapid and reliable (consistent) on-line management ofvarious data generations.

SUMMARY OF THE INVENTION

The invention is based on the object of specifying a data managementsystem which meets the above-mentioned requirements.

In general terms the present invention is a data management system of areal-time system. A transaction management system controls transactionsbetween users and the data management system, a transaction being asequence of accesses to logically interdependent data. An access datastructure is inserted in the course of a transaction by the transactionmanagement system into the access path of a data object to be modified.The data structure has a separating filter with a first output to theold image of the data object and a second output to the new image of thedata object. A generations management system manages the new datageneration produced in the course of a transaction after the ending ofthe transaction on the basis of the access data structures (TGSE)inserted by the transaction.

The functional coupling of the transaction control with the generationsmanagement via a shared access, data structure to the data objects ofthe data management system has the effect that the management of variousdata generations is carried out on the basis of the same data objects asare also used by the transaction management system. This allows rapidand reliable on-line management.

One embodiment of the present invention has a management data structure,with which the transaction management system combines the access datastructures inserted in the course of a transaction by linking themtogether to form a data generation with a specific generationidentifier. The generation identifier subsequently is transferred to thegenerations management system for management of the data generationcombined in this way. By this embodiment, the new data objects generatedin the course of a transaction are combined to form a data generationand are consequently uniquely identifiable according to the sequence inwhich they are generated on the basis of a GEN_ID. This makes itpossible for the generations management system for example to delete ano longer required data generation as a whole, i.e. by a single deleteinstruction.

In another embodiment the generations management system is a readingmanagement system, which controls logically associated read accesses,so-called reading sequences. The reading management system uses thegeneration identifier transferred to the generations management systemin order to carry out a consistent reading sequence access. Thisembodiment allows reading sequences to be carried out in parallel with atransaction.

In a further embodiment the access data structure has a barring field,with which a transaction can reserve exclusively for itself access to adata object behind it by storing a transaction identifier. By thisembodiment, access by transactions parallel to a transaction to the samedata object is prevented.

In yet another embodiment the access data structures are dynamicallyassigned to the data objects. The dynamic assignment allows the handlingof data objects of various granularity. This means that a TGSE can beassigned both to a data object of smallest granularity (data element)and to a data object of coarser granularity (data group). The saiddynamic assignability is achieved by the TGSEs being generated eitherdynamically as required, or taken from a common pool.

In a further embodiment the data layout of an access data structure isdesigned such that the first output of the separating filter of anaccess data structure can also point ot an older access data structure.By this embodiment, the TGSEs can be linked together by the transactionmanagement system according to the sequence in which they were createdto form a generation tree, which is subsequently managed by thegenerations management system. This embodiment presupposes the dynamicassignment of the TGSEs.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of the present invention which are believed to be novel,are set forth with particularity in the appended claims. The invention,together with further objects and advantages, may best be understood byreference to the following description taken in conjunction with theaccompanying drawings, in the several Figures of which like referencenumerals identify like elements, and in which:

In the drawing, the arrows between the system blocks represent afunctional relationship (for example a procedure call, the head of anarrow pointing to the procedure called up);

FIGS. 1 and 2 show the structure of a data management system EDBaccording to the invention, which can be accessed by variousapplications APPL;

FIG. 3 shows the preparation phase and the activation phase of atransaction;

FIG. 4 shows the structure of the central access control system;

FIG. 5 shows the architecture of the separating filter pool;

FIG. 6 shows the architecture of a transaction leaf;

FIG. 7 shows the composition of a separating filter structure;

FIG. 8 shows the structure of the logbook for managing transactions;

FIG. 9 shows the structure of the scope table;

FIG. 10 shows a flowchart of the procedure for transaction datatransfer;

FIG. 11 shows a flowchart of the procedure for transferring the entriesin the header of the separating filter pool;

FIG. 12 shows the flowchart of the procedure that runs through theseparating filter structure chain and that transfers linkinginformation;

FIG. 13 shows the flowchart of a procedure that opens a transactiontransferring the process group identifier to the access control systemas the input parameter;

FIG. 14 shows the flowchart of a procedure that allows the user tobreak-off a transaction activated by him;

FIG. 15 shows the flowchart of a proceudre that ends the preparationphase and opens the activation phase of a transaction;

FIG. 16 shows a generation tree for a particular data object;

FIG. 17 shows the flowchart of the transaction post-processing system;

FIG. 18 shows the access data structure introduced in connection withthe generations management system;

FIG. 19 shows the flowchart of a procedure that causes a readingsequence to be started;

FIG. 20 shows a flowchart of the procedure that ends a reading sequenceand that releases all data objects belonging to the generationidentifier of the reading sequence;

FIG. 21 shows a flowchart of the procedure that handles access conflictsin the preparation phase of a transaction;

FIG. 22 shows a flowchart of the procedure that handles conflictsbetween the transaction post-processing system and a reading sequence inthe generation phase of a transaction;

FIG. 23 shows a procedure that carries out an individual reading action;

FIG. 24 shows the structure of a data access path; and

FIG. 25 shows a procedure for data access.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The data management system comprises two layers, namely anapplication-specific system layer, which is referred to in the followingas application-specific database ADB, and an application-independentsystem layer, which is referred to in the following as generic databaseGDB.

The generic database GDB comprises central and local functions, thecentral functions being realized in a central control system CU and thelocal functions being realized in generic modules GM.

The central control system CU contains a central access control systemCTCC, which centrally controls accesses (individual accesses or accesssequences), general access algorithms ALG, a saving system NVSI, whichrealizes the interface with a backing store for saving the user data, adata pool VLP for managing data of variable length and a centraldistribution system DDFC, which serves for the distribution of updateduser data to the various processors of the real-time system.

A generic module GM represents a definition module for the descriptionof a data container, which contains data structures for storing the userdata and also the access structures required for this purpose, i.e.addressing methods and elementary access procedures. In addition, thegeneric modules contain additional structures for supporting the centralfunctional system, i.e. structures for supporting coordination and theensuring of consistency (local access control system CTCL), and alsostructures for supporting the distribution of the user data to variousplatforms (local data distribution system DDFL). The description of saidstructures in the generic module in this case takes place in a wayindependent of the user, i.e. in a way independent of the data layout ofthe data structures.

Different types of generic modules are produced by combining modules(for example local access control system CTCL, local distribution systemDDFL and additional data definitions necessary for this, variousaddressing methods). The variants are determined by the requirementsarising from the data modeling of the corresponding application.

Each generic module contains a set of elementary access proceduresconcerning the control of an individual access. This set comprises aprocedure GET for reading user data, a procedure SET for modifying userdata and also procedures CREATE and DELETE for creating and deletingdata elements of the user. Access to the data of a user is possible onlyby means of these special access procedures (data encapsulation). Datawith a corresponding persistence requirement are saved in the core-imageformat on a backing store. This ensures that the current data areavailable as quickly as possible after a restart of the switchingcomputer with the associated loading operation.

The application-specific database ADB comprises views and moduleinstances, the module instances being produced from the generic modulesby instantiation.

Said instantiation has the effect of initializing the data containers(generic modules) with specific data declarations, whereby the datastructures and the access algorithms to these data structures arebrought into relation with one another. The views form the interfacewith the current application APPL. They consequently represent thelogical picture of the conceptual data model of this application.

The access control system controls access by users to the datamanagement system EDB and thereby ensures that an updating operationtakes the data in the data management system from a consistent initialstate into a consistent end state. To ensure this consistency, theaccess control system handles access sequences (transactions or readingsequences) in an integral (atomic) way, i.e. a transaction is, forexample, either carried out in its entirety or rejected in its entirety.

In addition, the access control system coordinates the simultaneousaccess of access sequences parallel to one another.

The access control system comprises the CTCC, which carries out for theuser those control jobs (for example START_TA, DO_TA, ABORT_TA) whichconcern the controlling of an access sequence in its entirety.

The central data pool VLP manages semi-permanent and transient data ofvariable length. It comprises both the data and a set of primitives, inorder to store and manipulate the data looked after by it.

All the data managed by the central data pool are encapsulated by thedata pool. All accesses to these data can thus take place only via saidprimitives. Said module instances can have a block of any desired lengthreserved from the data pool, each reserved data block being identifiedby a logical key assigned during its reservation.

The generic access algorithms ALG comprise functions which are common toall the generic modules, namely on the one hand algorithms for thelogical organization of the data maintenance (for example linked list,binary tree), on the other hand mechanisms for physically storing thedata, i.e. data-structure-independent paths through database-internalmanagement or access structures. The generic access algorithms arecalled up exclusively from the generic modules.

The DDFC controls the transfer of user data from one platform(processor) to other platforms (processors) and thereby ensures dataconsistency between various platforms (processors). The DDFC isdynamically called up by a DDFL of a user module.

As already mentioned, a generic module serves as a data container, whichdescribes data structures and also specific access algorithms for thesedata structures in an application-independent way, i.e. in a mannerindependent of the data layout. A generic module comprises a set ofaccess procedures to the data management system, which it makesavailable to the respective application in order in this way to realizea reading or writing access to the data contained in the genericdatabase GDB.

On account of the internal architecture of a generic module, whichdistinguishes between data-structure-specific parts and general parts ofthe data access and of the data handling, general functions can bedeclared as generic algorithms ALG, which can be used by each genericmodule, since they are contained in the central module CM of the genericdatabase. In addition, the generic modules use other general functions,which are made available by the central access control system CTCC andthe data pool VLP.

A main purpose of the introduction of generic modules is the reusabilityand resubstitutability of software. The generic modules form a library,from which application-specific object classes can be produced byinstantiation, i.e. by the substituting of general data layoutinformation (space savers, in CHILL for example ANY_ASSIGN) by specificlayout information. The application can select suitable generic modules,instantiate them and combine the instantiated modules to form one ormore views.

The insertion of the application procedure layer VIEW between theapplication and the user module achieves the effect that the respectiveapplication is independent of the logical data structures. With the aidof an application procedure, one or more user modules are accessed, oneuser module in each case managing one object class. An applicationprocedure contains as parameters the desired attributes of therespective data object, these parameters being return parameters, whichare returned to the application after execution of the user procedure.The application procedure consequently has the effect of providing theapplication with its own way of viewing the stored application data.Changes to the logical data structures consequently have no effects onthe applications.

An application or a user uses for the management of its or his user dataexclusively the application procedures VIEW. For the consistentamendment of dependent data, a corresponding sequence of user procedurecalls is characterized by commands to the central access control systemas a transaction. The carrying out of the transaction and also thesaving of the data on the backing store and the distribution of the dataare performed in an independent way by the data management system andare consequently completely invisible for the user.

FIG. 3 shows the preparation phase and the activation phase of atransaction.

In the preparation phase, controlled by the user, the transaction isbuilt up step by step, in that the access procedures (SET, GET, etc.)for individual accesses are called up one after the other by the user.In principle, any number of individual accesses may be initiated withina transaction by calling up the corresponding access procedures.

The preparation phase is started by the procedure START_TA and ended bythe procedure DO_TA. The procedure START_TA assigns the transaction atransaction identifier TA_ID and passes it on to the user. The user thenuses this TA_ID as an input parameter when calling up the accessprocedures for individual accesses.

In the preparation phase, the calls of the access procedures arerecorded and any amendments of the data affected by the access areprepared. In the preparation phase, the user has the possibility ofrejecting the transaction by calling up the procedure ABORT_TA.

Calling up the procedure DO_TA at the same time has the effect ofstarting the activation phase, which is controlled exclusively by thecentral access control system and therefore runs independently of usercalls. In the activation phase, consequently no further calls forindividual accesses can be taken into consideration.

In the preparation phase, the coordination of a transaction is carriedout, i.e. all the collision cases with other parallel transactions areidentified and coordinated. The coordination in this case takes place bythose transactions which were started earlier being allowed to continue,whereas other parallel transactions are rejected by a correspondingnegative acknowledgement being returned to the user. Since all collisioncases are consequently resolved in the preparation phase, transactionscan be carried out independently of one another in the activation phase.

FIG. 4 shows the structure of the central access control system CTCC.The central access control system CTCC comprises a transactionmanagement system TMS, a generations management system TMS, a resourcesmanagement system RMS and a collision management system CMS.

The transaction management system TMS controls the transaction-orientedaccess to the data objects OCI of the data management system.

The generations management system GMS manages the data generationsproduced in the course of transactions on the basis of a generationidentifier GEN_ID allocated by the transaction management system to atransaction during the activation phase. This management comprises theupdating of a newly produced data generation, i.e. the transferring ofthe new data generation to its final storage locations in the mainmemory and/or on the disk. In addition, said management comprises thecontrolling of reading sequences (sequences of logically associated readaccesses to the data objects of the data management system).

This type of management makes it possible for a group of data objects ofone and the same generation to be read in the course of a readingsequence, while a transaction takes place in parallel with this.

The resources management system RMS manages the access data structureswhich are used during access of the transaction management system and/orthe generations management system.

The collision management system CMS coordinates writing accesses to oneand the same data object which are triggered by parallel transactionsand prevents the oldest data generation from being deleted while at thesame time a reading sequence wants to have reading access to dataobjects of this data generation.

The RMS compromises as the largest data structure a separating filterpool TGS_POOL, which is used both by the transaction management systemTMS and by the generations management system. The separating filter poolserves the purpose of maintaining (buffer-storing) new data(transaction-oriented inputs) received by the transaction managementsystem TMS in the course of a transaction, until they have been storedin their final storage locations in the memory and on the disk by thegenerations management system.

The RMS further comprises a logbook TG_LOG, which makes possiblesuitable management of the transactions, a scope table SCOPE_TAB, whichserves for managing the various data generations, and as the smallestadministrable data structure the already mentioned separating filterstructure TGSE.

FIG. 5 shows the architecture of the separating filter pool TGS_POOL.

The architecture of the separating filter pool comprises 10 transactionleaves TL with corresponding headers 0 to 10. It follows from this thatthe transaction management system supports 10 transactions in a parallelway, since each transaction leaf TL is reserved exclusively for aspecific transaction, in that an assigned transaction identifier TA_IDis entered into the corresponding data field of the associated header.An additional eleventh transaction leaf is provided in order to allow anactive transaction to continue in its execution even when its associatedtransaction leaf is running short due to a lack of adequate availablememory (indicated by a data field FREE_MEMORY with the header).

In order that a transaction leaf can be made available by the resourcesmanagement system, three conditions must be met. As the first condition,the free storage location of the heap, which is indicated in a datafield FREE_MEMORY of the header, must lie above a certain threshold. Asthe second condition, a data field TA_ID of the header must not have anyentry. As the third condition, a data field STATE of the header, whichindicates the state of a transaction, must indicate the state “free”.

The data content of the data field STATE is a transient parameter withinthe semi-permanent transaction leaf which is necessary to continue toreserve a transaction leaf during an updating phase, although thesemi-permanent parameters FREE_MEMORY and TA_ID are already indicatingthe reusability of the transaction leaf for other transactions.

FIG. 6 shows the architecture of a transaction leaf, in particular thedata fields contained in the header of the transaction leaf TGL.

A data field BEGIN_USED_AREA shows the beginning of the memory areawhich is being used by the transaction leaf TGL for storing the inputdata of a transaction. A data field END_USED_AREA indicates the end ofsaid memory area. The data field END_USED_AREA at the same timeindicates the beginning of the memory area which can be used by afurther TGL.

A data field LENGTH_USED_AREA contains a redundant parameter formonitoring purposes, which indicates the difference of the memorybetween the content of the data field BEGIN_USED_AREA and the data fieldEND_USED_AREA.

Finally, a data field END_UPDATED_AREA indicates the momentary end ofthe memory area already transferred onto the disk by the transaction.

FIG. 7 shows the composition of a separating filter structure TGSE,which represents the smallest data structure managed within theseparating filter pool, and which is assigned to a transaction by aprimitive of the transaction management system or of the generationsmanagement system and is set into a transaction leaf TGL as an overlaystructure.

A data field PATTERN represents a parameter for monitoring purposeswhich indicates that the separating filter structure is linked with acomplete memory block which has been assigned to the transaction by thedata pool VLP.

A transaction identifier TA_ID, which denotes that transaction which hasrequested (assigned) the separating filter structure and which reservesexclusively for the associated transaction the data structure appendedto the separating filter structure, for example a data object.

A command identifier COM_ID and a logical key LOG_KEY represent protocolinformation per data object serving for communication with the genericmodules.

A backward reference PTR_BACK_REF, which represents a pointer to anentry in a translator device for the logical key, or in the case of ageneration tree a pointer to the previous separating filter structure. Aflag F distinguishes between the two said cases.

A pointer PTR_OLD_DATA, which represents a pointer to the old image of adata object, or in the case of a generation tree a pointer to the nextseparating filter structure. The two said cases are in turndistinguished by a flag F.

A pointer PTR_NEW_DATA, which represents a pointer to a new image of adata object, a flag F indicating whether the data of the new image areto be downloaded onto other leaf forms.

A data field TGSE_L, which represents the physical length of the datastored in a data field NEW_DATA.

A data field OLD_BLK_L, which represents the physical length of the oldmemory block assigned by the data pool VLP.

A data field NEW_BLK_L, which represents the physical length of the newmemory block assigned by the data pool VLP.

A pointer PTR_NEXT_TGSE, which represents a pointer, assigned in thesame transaction, to the next separating filter structure.

A data field NEW_DATA, which represents a data container for receivingthe new data.

The description of the separating filter structure TGSE with referenceto FIG. 7 brings to an end the description of the semi-permanentseparating filter pool TGS_POOL and there now follows the description ofa further data structure of the RMS, the so-called logbook TG_LOG.

FIG. 8 shows the structure of the logbook TG_LOG for managingtransactions. The semi-permanent logbook represents a table in which aline is respectively reserved for each existing transaction identifierTA_ID of the separating filter pool.

The semi-permanent logbook represents a table for managing transactionswhich contain in their header a current transaction identifierTA_ID_ACT. The value of this current transaction identifier is assignedto each newly started transaction and is then incremented. The currenttransaction identifier in the header is implemented as a cyclicalcounter.

The fields of an exemplary line of the logbook are explained in moredetail below.

A data field PROCGRP_ID, which contains information on the process groupwhich the transaction has started.

A status field STATUS contains information on the status (phase) of atransaction. A transaction is essentially divided into three phases,namely a preparation phase and an activation phase, which are both underthe control of the transaction management system, and a generationphase, which is under the control of the generations management system,and in which the new data are transported to their final storagelocations in the memory and on the disk. The individual steps of saiddifferent phases are recorded as status information in the status field.This recording allows the consistency management system to respond in asuitable way to events which trigger a restarting of the real-timesystem.

FIG. 9 shows the structure of the scope table SCOPE_TAB, the purpose ofwhich is explained in more detail below.

The beginning of a transaction is marked in a unique way by theallocation of a transaction identifier TA_ID. The producing of a newdata generation within the activation phase of a transactionadditionally requires the allocation of a generation identifier, whichcan likewise be identified in a unique way. Since all the actionsexecuted in the generation phase of the transaction are carried out onthe basis of the generation identifier, a semi-permanent data structure,namely said scope table SCOPE_TAB, must be available in order to be ableto link the generation identifier with the transaction identifier andthereby be able to access the data newly introduced in a transaction.

A further purpose of the scope table is to record the overall scope ofdata generations which is managed by the generations management system.The transaction management system uses the scope table to assign ageneration identifier to a transaction. For this reason, the scope tablealso contains a pool of generation identifiers.

The overall scope of generations which are recorded in the scope tableis described by a parameter GEN_ID_OLD, which points to the end of thescope table, and a parameter GEN_ID_NEW, which contains a pointer to thebeginning of the scope table. The parameter GEN_ID_NEW further containsa pointer to the pool of the generation identifiers, which isimplemented as a cyclical counter.

The resource primitives contained in the RMS, which form a shell aroundthe access data structures of the access control system CTCC and makethese data structures transparent for all the other functional blocks ofthe access control system, are explained in more detail below. The useof these procedures is explained in more detail by flow charts in thefigures which follow.

A procedure APPOINT_TAID evaluates the transaction identifier pool,assigns the current transaction identifier to the transaction requestedand subsequently increases the value of the current transactionidentifier.

A procedure ALLOC_TGL evaluates the semi-permanent header of theseparating filter pool TGS_P, assigns a transaction leaf to thetransaction or detects a lack of resources and thereupon initiates atransaction post-processing with high priority.

A procedure ENTER_TG_LOGBOOK transfers transaction information, forexample information on the status of a transaction, into the logbookTG_LOG.

A procedure VERIFY_TAID verifies the transaction identifier TA_ID, whichhas been transferred by the user of the procedure DO_TA, which will beexplained in more detail later, to the control system as a parameter inorder to establish whether this transaction identifier is still recordedin the logbook.

A procedure DETMINE_TA_STATE determines the state of a transaction onthe basis of the corresponding entry in the logbook.

A procedure APPOINT_GENID evaluates the generation identifier pool,assigns a current generation identifier and increments the momentaryvalue of the current generation identifier.

A procedure ALLOC_TGSE represents a service procedure of the CTCC forthe ADB. It allows a module instance of the application-specificdatabase ADB, to assign to a transaction a semi-permanent separatingfilter structure TGSE for transaction-controlled inputs. The procedureALLOC_TGSE comprises the following activities:

checking of the set of input parameters transferred from the moduleinstance

checking of available access data structures, and also calling up of ahighly prioritized transaction post-processing if adequate storagecapacity is not available

copying of the new data into the assigned separating filter structureand insertion of the separating filter structure into the associatedseparating filter structure chain

calling up of a procedure TA_CONTRL, to be explained later, of thecollision management system and, in the case of no conflict, insertionof said separating filter structure into the data access part of thedata object concerned.

A procedure CONFIRM_TADATA progresses through the separating filterstructure chain and informs the data pool VLP in the case of a connectedmemory block of the data pool with the aid of the procedureCONFIRM_SEIZE.

A procedure DETMINE_TGSLNK evaluates the logbook TG_LOG and determinesfrom it the separating filter pointer TGS_LINK.

A procedure DETMINE_TGSEINFO evaluates a separating filter structureTGSE and determines from it certain information, for example thetransaction identifier TA_ID, or the type of linking of the separatingfilter structure from the data field PATTERN.

A procedure DETMINE_OLDTAID evaluates the logbook and determines from itthe smallest transaction identifier TA_ID recorded therein.

A procedure ENTER_TGSHEADER transfers status information of atransaction, for example the information disk errors, into thecorresponding status field of the header of the separating filter poolTGS_P.

A procedure TA_ROLLBCKMEM allows a reversal (roll backward) oftransaction-controlled inputs. This procedure carries out the followingactions:

it progresses through the separating filter structure chain of atransaction

in the case of memory blocks being incorporated in the separating filterstructure chain, it makes the data pool VLP release these memory blocks,

it informs the Platform New functional complex of the module instancerequesting the transaction if the command identifier corresponded to thecreate command,

it releases the corresponding separating filter structure from the dataaccess path,

it resets the entries in the header of the transaction leaf TGL and ofthe separating filter pool TGS_P.

The procedure TA_ROLLBCKMEM is also used in the case of a disk error.

A procedure TA_ROLLFORWARD makes it possible to continue (roll forward)transaction-controlled inputs in the case of recovery events andcontains for this purpose parts of the procedure DO_TA, explained later.The entry point into this contained procedure depends on the transactionstatus existing when the recovery event occurred.

More complex primitives of the resources management system RMS areexplained below with reference to FIGS. 10 to 12.

FIG. 10 shows a flow chart of the procedure DO_TADATA.

The procedure DO_TADATA causes transaction data transferred to theaccess control system to be passed on to the updating instance UPDATE,to be precise both for storing in the notebook NOTEBOOK and on the diskDISK. An input parameter TASK with the two possible values “TGSLEAF” or“VLP” determines in this case whether the procedure works with thetransaction data established by the entry in the header of thetransaction leaf or with those transaction data stored in acorresponding memory block in the data pool VLP. Possible outputparameters OUTPUT of said procedure are “disk error”, “NO_SUCCESS” and“SUCCESS”.

FIG. 11 represents the flow chart of a procedure DO_HEADER. Thisprocedure transfers the entries in the header of the separating filterpool, of the transaction leaf and of the logbook of a transaction to theupdating instance with the instruction to store in the notebook. Then,the procedure runs through the separating filter chain and transfers allthe headers of the memory blocks of the data pool containing linkinginformation likewise to the updating instance for storing in thenotebook. For reasons of consistency, this procedure must likewiseensure that header information concerning data with respect to accessdata structures is entered into the same notebook. If necessary, thisprocedure must also call up the updating instance with the instructionfor storing on the disk DISK. This procedure does not contain any inputparameters, while its output parameters are identical to the outputparameters of the procedure DO_TADATA. In addition, the procedurechanges the status entry of the transaction in the logbook twice, to beprecise the first time the status information TA_CLOSED is changed intothe status information TA_TGSHPREP and the second time the statusinformation TA_TGSHPREP is changed into the status informationTA_TGHSUCC, if in the course of the procedure the updating informationwith the instruction to store on disk was called up.

FIG. 12 shows the flow chart of a procedure DO_TGSE_ENTRY. Thisprocedure runs through the separating filter structure chain andtransfers linking information, which links a separating filter structureinto the data access path, to the updating instance with the instructionfor storing in the notebook. If necessary, it likewise initiates storingon the disk with the call UPDATE: DISK. The procedure has no inputparameter and, as output parameters, has the same parameters as theprevious procedure. In addition, the procedure changes possible statusinformation TA_TGSHPREP or TA_TGSHSUCC into the status informationTA_DISKPREP.

The interface procedures of the access control system with respect tothe module instances have now been explained. The interface proceduresof the access control system with respect to the user are explained inmore detail below with reference to FIGS. 13 to 15.

FIG. 13 shows the flow chart of a procedure START_TA. This procedureopens a transaction, transferring the process group identifier to theaccess control system as the input parameter. And as output parameters,it receives the parameters TA_ID and/or “LACK OF RESOURCES” indicated inFIG. 13. The status information is received in the course of thisprocedure from “NO_TRANS”.

FIG. 14 shows the flow chart of a procedure ABORT_TA. This procedureallows the user to break off again a transaction activated by him. Asthe input parameter, the user in this case transfers to the accesscontrol system the transaction identifier belonging to the transaction,whereupon the associated transaction is reversed by the procedure. Theoutput parameters of the procedure can in turn be taken from FIG. 14.The status information “TA_STARTED” or “TA_NODISKNB” possibly present atthe beginning of the procedure is changed by the procedure into thestatus information “TA_ABORTED”.

FIG. 15 shows the flow chart of a procedure DO_TA. This procedure endsthe preparation phase and opens the activation phase of a transaction.The input parameter of this procedure is the transaction identifierTA_ID, while the output parameters of this procedure can in turn betaken from FIG. 15. This status of a transaction is changed twice bythis procedure. The first time, the present status information“TA_STARTED” is changed into the status information “TA_CLOSED”. Thesecond time, the present status information “TA_CLOSED” is changed tothe status information “TA_DISKSUCC”, “TA_DISKNOSUCC” or “TA_NODISKNB”.

The generations management system is explained in more detail below.

As already mentioned, the generations management system controls thereading-oriented access to the data objects of the data managementsystem. The reading-oriented access in this case comprises a sequence oflogically interconnected reading requirements. Within such a sequence itis ensured that access is made to a consistent set of data objects, i.e.a set of data objects which is valid with respect to a specific point intime, to be precise even when a transaction is updating in parallel withthis one or more of the accessed data objects. To ensure thissimultaneity, the new image and old image of each data object are storedin a parallel way both in the main memory and on the disk. Thegeneration identifier GEN_ID, which is assigned to a transaction duringthe activation phase, is used by the generations management system inthe generation phase of a transaction in order to identify in a uniqueway the new data generation produced by the transaction.

If more than one updating has been carried out for a particular dataobject and more than one old data generation was kept in the memorythereby, a so-called generation tree begins to grow.

FIG. 16 shows an exemplary generation tree for a particular data object.The generation tree comprises three generations D1, D2 and D3. Theyoungest generation D3 is contained in a separating filter structure,while the oldest generation D1 is at its final location in the mainmemory. The data access path to the generation tree is realized by meansof a translator structure in the form of a list, which is referred to inthe following as translator list TRL. The record fields of thetranslator structure are activated by the access control system via alogical index and receive a physical pointer to a separating filterstructure or, if no generation tree exists, back to the data object inthe main memory. The record fields of the translator structure arehereafter referred to in keeping with their function as data linkfields.

For disassembling the generation tree, the generations management systemTMS (see FIG. 4) comprises a transaction post-processing system, whichtransfers all the data stored in the course of a transaction in thesemi-permanent separating filter pool TGS_P (input data) out of thelatter to its final storage locations in the main memory and on thedisk. The start of the transaction post-processing system thereforemarks the beginning of the generation phase for the transactionbelonging to this data. However, at the same time, the data of theoldest data generation lying under this newly introduced data are at thesame time finally destroyed by the transaction post-processing system.The start of the transaction post-processing system therefore marks theend of the generation phase for the transaction belonging to this data.

The transaction post-processing system is technically realized as aninternal transaction of the access control system and is thereforesynchronized and coordinated with respect to other transactions.

The transaction post-processing system is started for two differentreasons and therefore has two different process priorities. If thetransaction post-processing system is started in order to rectify a lackof resources in the TGS pool, it has a higher process priority than amanagement process. If the transaction post-processing system is startedin order to transfer the data newly introduced by a transaction to itsfinal storage locations, it has the same process priority as amanagement process.

FIG. 17 shows the flow chart of the transaction post-processing system,designations occurring therein being explained in more detail furtherbelow.

Those access data structures of the resource management system RMS whichserve exclusively for supporting the tasks of the generations managementsystem are explained in more detail below.

FIG. 18 shows the access data structure introduced in connection withthe generations management system, the so-called reading logbookSEQ_LOGBOOK, in which active reading sequences are recorded. With theaid of the reading logbook, it is ensured that a data object which isreached by an active reading sequence will not be physically erased bythe transaction post-processing system. The reading logbook also takespart in the timer supervision of reading sequences, since readingsequences which run for too long constitute a negative influence on thesystem. This participation consists in that the timer supervisioncyclically scans the entries in the reading logbook. If it therebydiscovers a reading sequence which has exceeded a certain time limit,this reading sequence is rejected.

The reading logbook contains a data field PROCGRP_ID, which containsinformation on the process group which the reading sequence has calledup. Like the corresponding field in the transaction logbook, this fieldserves to support the recovery post-processing.

The reading logbook further comprises a data field SEQ_STATUS, whichindicates to the transaction post-processing system a running activereading sequence and thereby excludes the possibility of a data objectbelonging to the generation identifier being physically erased.

Those resource primitives of the resources management system which areused exclusively by the generations management system and, like theresource primitives of the transaction management system, likewise forma shell around the access data structures of the resources managementsystem are explained in more detail below.

A procedure VERIFY_GENID verifies the generation identifier GEN_ID andtransmits it to the generations management system, which stores it inthe scope table SCOPE_TAB.

A procedure ALLOC_SEQREC assigns to a reading sequence at the beginninga record in the reading logbook corresponding to the generationidentifier.

A procedure ENTER_SEQLOG transfers a status information item of thereading sequence into the reading logbook.

A procedure DETMINE_GENIDOLD evaluates the scope table and determinesthe oldest generation identifier GEN_ID_OLD.

A procedure TRANS_GENTAID determines on the basis of the scope tablethat transaction identifier which corresponds to the generationidentifier transferred to this procedure.

A procedure POSTPROC_TGSE of the transaction post-processing system TAPPprogresses through the separating filter structure chain of atransaction and thereby carries out the following activities:

in the case of a low-prioritized transaction post-processing, it carriesout a collision check, in that it calls up a procedure GEN_CONCTRL ofthe collision management system, which is explained in more detail laterwith reference to FIG. 22,

it copies the content of a separating filter structure to the finalstorage location in the main memory, releases the separating filterstructure from the data access path in the case of a linked memory blockof the data pool and informs the data pool of this,

it transfers transaction data into the buffer memory of the transactionand initiates, if necessary, an intermediate updating operation,

it updates the header of the transaction leaf and enters the separatingfilter structure number NO_TGSE into the transaction logbook.

A procedure POSTPROC_HEADER of the transaction post-processing system,which comprises the following activities:

it changes the transient status information in the header of theseparating filter pool to the value “TA_CLOSED”,

it clears the access field (barring field) to the header of theseparating filter pool and to the transaction leaf of the transaction,

it changes the status information in the transaction logbook to thevalue “GEN_DISKPREP” and enters the corresponding record in the headerof the separating filter pool,

it transfers the data in the corresponding record of the header of theseparating filter pool and the data in the transaction logbook into abuffer memory NOTEBOOK (NB,

it initiates and controls the updating operation on the disk DISK.

A procedure GEN_ROLLBCK allows a reversal (roll backward) oftransactions in the generation phase and for this purpose carries outthe following actions:

it progresses through the semi-permanent filter separating structurechain,

it evaluates the linking data between the separating filter structureand the data access path, re-links, if necessary, the separating filterstructure with the data access path, transfers the linking data to thebuffer memory and, if necessary, initiates an intermediate updatingoperation onto the disk,

it calls up the updating instance UPDATE to initiate the updating ontothe disk,

it uses the procedure CONFIRM_TADATA, which is likewise used by thetransaction management system and has already been explained, earlier.

The interface procedures between the user and the generations managementsystem is explained in more detail below with reference to FIGS. 19 and20.

FIG. 19 shows the flow chart of a procedure BEGIN_GETSEQUENCE, thecalling up of which by the user causes a reading sequence to be started.This procedure assigns to the reading sequence a record field in thereading logbook corresponding to the momentarily current generationidentifier and changes the parameter SEQ_STATUS to the value “closed”.This ensures that no data object which belongs to the current generationidentifier can be erased by the transaction post-processing. Inaddition, a timer supervision is called up by this procedure, in orderto avoid a negative influence on the system by a long-running readingsequence. Serving as the input parameter of this procedure is theparameter PROCGRP_ID. Output parameters of this procedure are thegeneration identifier GEN_ID, and also a message parameter, whichcomprises the messages “lack of resources” and “accepted”.

FIG. 20 shows the flow chart of the procedure END_GETSEQUENCE, whichends a reading sequence and releases for transaction post-processing allthe data objects belonging to the generation identifier of the readingsequence, in that it changes the parameter SEQ_STATUS to the value“FREE”. The input parameter of this procedure is the parameter GEN_ID.The output parameter of this procedure is a message parameter with themessages “out of scope” or “accepted”.

The collision management system, which handles access conflicts ofsimultaneously occuring transactions, which cannot be entirely avoidedfrom the outset by planning measures, is explained in more detail below.The collision management system essentially comprises two procedures,namely a procedure TA_CONCTRL, which handles access collisions in thephase of a transaction under the control of the transaction managementsystem, and a procedure GEN_CONCTRL, which handles access collisions inthe phase of a transaction under the control of the generationsmanagement system.

FIG. 21 shows a flow chart of the procedure TA_CONCTRL, which isembedded in the procedure ALLOC_TGSE and handles access conflicts in thepreparation phase of a transaction if two transactions want to linktheir separating filter structure with the same data link field of thedata access path to a data object. To resolve this conflict situation, adata link field (data link field) contains not only the pointer fieldbut also an access field, in which a transaction stores its transactionidentifier if the access field is not yet closed, i.e. if no othertransaction identifier is already stored in the access field. Thelinking of the separating filter structure to the data access path isthen brought about by leaving the physical pointer pointing to theseparating filter structure. A separating filter structure which is tobe linked with a specific data link field in the course of a transactiongets into a collision conflict if another active transaction has alreadyoccupied the access field of this data link field. The coordination ofthis conflict is regulated as follows:

a transaction in the preparation phase which has reserved an accessfield to a data object first is then continued. The other transaction isrejected.

A transaction which has already reached the activation phase is nolonger rejected on the basis of access conflicts.

FIG. 22 shows a flow chart of the procedure GEN_CONCTRL, which isembedded in the procedure POSTPROCR_TGSE of the transactionpost-processing system and handles conflicts between the transactionpost-processing system and a reading sequence in the generation phase ofa transaction. To be more precise, in the case of a low-prioritizedtransaction post-processing, the procedure GEN_CONCTRL prevents a datageneration being erased if a reading sequence wants to access this datageneration. In contrast with this, in the case of a high-prioritizedtransaction post-processing, which is carried out in the case of a lackof resources for the access control system, the reading sequence isrejected and the data generation is erased.

The individual actions combined in a transaction or a reading sequence,or to be more precise the procedures for carrying out these individualactions, are explained in more detail below with reference to FIGS. 23,24 and 25.

FIG. 23 shows a procedure GET, which is contained in a user module andcarries out an individual reading action, it being possible for it to becalled up both in the course of a transaction and in the course of areading sequence. Input parameters of the procedure GET are anidentifier of the reading action and a logical key, which leads throughthe data access path to the data object. The identifier of thetransaction is a transaction identifier TA_ID if the procedure GET isused within a transaction. In the other case, namely if the procedureGET is used within a reading sequence, the identifier is a generationidentifier GEN_ID. Output parameters of the procedure GET are the dataobject and a message parameter for the return of check messages.

First of all, lists of the data access path are run through on the basisof the logical key.

FIG. 24 shows the exemplary structure of a data access path, whichcomprises a plurality of lists and is stored in the user-independentdata module VLP. The data access path comprises a data block list UBL,the list elements of which represent pointers to data blocks UB, as wellas, within a data block UB, an object class list OCL and data objectlists DOL. The logical key comprises indexes of said lists, namely theindexes UBL_IX, OCL_IX and DOL_IX, on the basis of which finally thepointer to a data object OCI or a separation filter structure TGSE canbe determined.

First of all the procedure GET runs through the data access path, inthat it calls up the procedure RD_BLK, which is implemented in theuser-independent central data pool VLP. This procedure supplies as thereturn value the physical pointer to a data object list DOL. In the caseof a transaction, this pointer is not used until the activation phase,following the preparation phase of the transaction, in order to executethe actual access.

Next, the procedure ACCESS_OCI with the parameters “pointer to the dataobject list DOL” and “DOL_IX” is called up. This procedure investigates,inter alia, the header of the DOL and determines whether it is a validindex in the case of the transferred parameter “DOL_IX”.

If the index DOL_IX is valid, subsequently the list field of the listDOL corresponding to the index DOL_IX is analyzed. It is therebyinvestigated whether the identifier ID stored in the access field(barring field) of the list field is a transaction identifier or ageneration identifier. This is represented in FIG. 23 by a branch block.

If it is a generation identifier, the generation tree adjoining the dataaccess path is evaluated on the basis of the procedure EVAL_GENTREE andthe physical pointer corresponding to the generation identifier is thenreturned to the data object.

If the identifier ID is a transaction identifier, the procedureALLOC_TGSE is called up, which prepares a subsequent writing action by aprocedure SET, and the data object is barred with respect to othertransactions. This also has the consequence that, during the activationphase of the transaction, the transaction post-processing cannot carryout any actions with respect to this data object.

A user-specific data module GMI comprises furthermore a procedure SET,which modifies a data object within a transaction. Input parameters ofthis procedure are a transaction identifier TA_ID, a logical key forleading through the data access path and a pointer to the data to benewly taken over as well as an indication of the length of the new data.The output parameter is a parameter for acknowledgements.

Like the procedure GET, the procedure SET (see FIG. 25) comprises dataaccess, which is carried out with the aid of the procedures RD_BLK andACCESS_OCI. Thereafter, the procedure ALLOC_TGSE contained in the CTCCis called up, it requests a new separating filter structure TGSE andcopies the new data or the new data object into the separating filterstructure. If the procedure SET was prepared by the procedure GET, saidassignment of a new separating filter structure does not take place.

The user-specific data modules comprise furthermore a procedure CREATE,which extends an object class by a data object, and a procedure DELETE,which reduces an object class by a data object. The two said proceduresare of no significance for the description of the invention and aretherefore not explained in any more detail.

The invention is not limited to the particular details of the apparatusdepicted and other modifications and applications are contemplated.Certain other changes may be made in the above described apparatuswithout departing from the true spirit and scope of the invention hereininvolved. It is intended, therefore, that the subject matter in theabove depiction shall be interpreted as illustrative and not in alimiting sense.

What is claimed is:
 1. A data management system of a real-time system, comprising: a) a transaction management system, which controls transactions between users and the data management system, a transaction being a sequence of accesses to logically interdependent data; b) an access data structure, which during a single transaction is inserted by the transaction management system into an access path of a data object to be modified, the access data structure inserted during said single transaction having a separating filter with both a first output to an old image of the data object and a second output to a new image of the data object; and c) a generations management system, which manages generation of new data which is produced during a transaction, after an ending of the transaction based on the access data structures inserted by the transaction management system.
 2. The data management system of a real-time system as claimed in claim 1, wherein the data management system further comprises a management data structure, with which the transaction management system combines the access data structures inserted during a transaction by linking them together to form a data generation with a specific generation identifier, the generation identifier subsequently being transferred to the generations management system for management of the data generation combined in this way.
 3. The data management system of a real-time system as claimed in claim 1, wherein the generations management system comprises a reading management system, which controls logically associated read accesses, the reading management system using the generation identifier transferred to the generations management system for carrying out a consistent reading sequence access.
 4. The data management system of a real-time system as claimed in claim 1, wherein the access data structure comprises a barring field, with which a transaction can reserve exclusively for itself access to a data object appended to said access data structure by storing a transaction identifier.
 5. The data management system of a real-time system as claimed in claim 1, wherein the access data structures are dynamically assigned to the data objects.
 6. The data management system of a real-time system as claimed in claim 5, wherein the data layout of an access data structure is structured such that the first output of the separating filter of an access data structure can also point to an older access data structure.
 7. The data management system of a real-time system as claimed in claim 3, wherein the logically associated accesses are reading sequences. 